Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_0399/24

Internet Message Format | 1994-08-27 | 3.8 KB

From: Stephen Usher <[e-mail]>
Subject: Re: libraries
Date: Mon, 18 Jan 93 9:22:06 BST
In-Reply-To: <[e-mail]>; from "Michal Jaegermann" at Jan 17, 93 8:16 pm

>I think that splitting header files AND libraries into common,
>MiNT specific and TOS specific is something which should have been
>done a long time ago.  Actually Jwahar, Eric and me we were talking
>about that some while ago but there is quite a bit of work involved
>in it.  Maybe you noticed that for some while Jwahar was moving
>quietly in this direction.
>
>Still, in my opinion, a requirement for something like an explicit
>#include <tos/foo.h> would be a mistake which will cause immediate
>compatibility headaches, neccessity to edit sources, lotsa of
>superfluous #ifdef...#endif and the like.
>
>I think that instead we should modify a little bit an organization
>and a compiler driver.  Let us assume that we have two different files
>.../include/tos/stdio.h and .../include/mint/stdio.h.  In sources
>one should have one, unequivocal, directive '#include <stdio.h>'.
>A compiler driver (like gcc, for example) with a flag '-tos' should
>search for header files like this:
>  .../include/tos/,.../include, <whatever else in include path>
>and with '-mint' flag like this:
>  .../include/mint/,.../include, <whatever else in include path>
>with a similar arrangement for libraries.  One of flags '-mint' '-tos'
>could/should be a default depending on a compiler configuration.
>You risk that way at most a neccessity to recompile a driver, which
>is really small program and can be redone even on the smallest
>machines.  So what are your comments?

I think this would be a mistake. If possible the libraries should be unified
and auto sensing so we don't have to worry if we got the correct binary from
the archive. As for having separate sets of header files.. isn't it bad
enough that we have two sets of libraries cluttering up our meagre disk
space?

>
>I think also that LF vs. CR/LF controversy is based on a
>misunderstanding.  Maybe I got it wrong, but I thought that an
>original proposition was about a form in which sources and updates are
>distributed.  It is true that 'patch' will barf on you (although
>'patch -l' should be ok, but it may other undesirable side effects) if
>you have sources in one form and diffs in another but they are easily
>convertible one way or another and there is likely 1001 ways to
>acomplish that conversion.  Jwahar is using LF line terminator since
>he keeps and maintains library sources on a Unix machine for the sake
>of convenience but this does not mean that anybody else have to do
>the same thing.  (Sending them via zmodem in an unpacked form as
>text files will do that conversion for you - both ways :-)).

Zmodem's fine if you have an 8bit clean channel. Some of us don't. Also most
of the stuff we are downloading are zoo archives which are binary data.

>
>Julian asks why DTA is named _DTA in gcc header files.  I can guess
>that this was done to be consistent with a convention that
>internal "vendor names" start with '_' to avoid a polution of a name
>space.  If Pure C needs DTA instead this is easy to resolve by
>supplying in a "compatibility" header file "#define DTA _DTA".
>As for conflicts in prototypes I really cannot tell.  I have never
>seen Pure C compiler and I do not know where conflicts do occure.
>I can only tell that gcc headers try very hard to follow ANSI C
>Standard and comparing with other "more or less" Standard C compilers
>on other machines are pretty good at it.

I agree, the GCC libs do the right thing and tally (mostly) with the Atari
docs (at least the one I have).

>
>   Michal
>

Steve

--
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: [e-mail]. Tel: Oxford [phone].